wafer.space Community - 📝-project-template

Also having CTS done separately on different blocks is dangerous as the clock tree depth may be different between blocks causing unexpected hold/setup violations for signals going between different blocks. If I'm not mistaken, LibreLane supports P&R on subblocks separately but still CTS on top block.

I know that CTS recently(-ish) got the ability to place macro at different depth of the CTS depending on the min/max clock delay specified in the liberty file of the macros/sub-blocks. ( https://github.com/The-OpenROAD-Project/OpenROAD/issues/3759 )

Cool, thanks for all the tips. I guess I will have a play around with this and see what I come up with.

But TBH I'm not sure how common it is to harden various block independently. That prevents optimization at boundary and also cost area since macro are rectangular and blocks often harden more into blob shapes.

8:36 a.m.

The only case where I see blocks hardened as macro are highly optimized ones where there was significant manual/scripted/layout/... work to make it a separate block. Something like a SRAM / memory or something like that.

8:36 a.m.

Or of course analog-ish block like say a PLL.

8:36 a.m.

But I wouldn't say ... harden a SPI controller independently ... that'd be a lot of headache for virtually no benefits.

8:37 a.m.

Just my 2 cts ...

Thanks, appreciate the input. I'm not super familiar with this field and trying to learn. In my case, I'm studying SIMD lanes and thought to make the separate arithmetic units (say 32 of them) as I thought this is how 'real' designs are made. I had some severe congestion issues when trying to synth my top module

Olle

Thanks, appreciate the input. I'm not super familiar with this field and trying to learn. In my case, I'm studying SIMD lanes and thought to make the separate arithmetic units (say 32 of them) as I thought this is how 'real' designs are made. I had some severe congestion issues when trying to synth my top module

I'd consider looking into the placement/partitioning tuning options in librelane for how to possibly selectively nudge the density around congested blocks to be lower and/or nudge SIMD lanes to be substantially less-overlapping. If your SIMD instructions are complex enough it might be practical to force them into slices, though, to spend much more compute on optimizing a slice, afforded by then getting to just make 31 already-routed copies at no extra PnR compute for the dense intra-slice situation.

namibj

I'd consider looking into the placement/partitioning tuning options in librelane for how to possibly selectively nudge the density around congested blocks to be lower and/or nudge SIMD lanes to be substantially less-overlapping. If your SIMD instructions are complex enough it might be practical to force them into slices, though, to spend much more compute on optimizing a slice, afforded by then getting to just make 31 already-routed copies at no extra PnR compute for the dense intra-slice situation.

Right. Yeah, its basically option 2 I have been considering (slicing it into a module and instancing it 32 times). At least, that makes sense in my mind. But I understand now that this is a bit more complex than I first thought. I believe I need to specify where I/O to this 'macro' will be placed (like inputs on the left, outputs on the right), but I'm also having issues getting this to close. Well.

7:19 p.m.

Thanks for all the tips!

Olle

Right. Yeah, its basically option 2 I have been considering (slicing it into a module and instancing it 32 times). At least, that makes sense in my mind. But I understand now that this is a bit more complex than I first thought. I believe I need to specify where I/O to this 'macro' will be placed (like inputs on the left, outputs on the right), but I'm also having issues getting this to close. Well.

yeah ideally you'd somehow be able to tell it just that in this region there are 32 identical slices and that they're instances for the 32-wide datapath around it, and that it has to figure out PnR inside, outside, and has to figure out how it likes the ports placed. I'd probably give it opportunity to just place the ports wherever on the grid on one side in teh small slice and just roll with what it likes best there.

Minor update! It turns out that the changes to the density rules have not yet been upstreamed to Open PDKs from our legacy wafer.space PDK fork. This update addresses this issue.

Project Template 1.5.7

Update PDK to d658698b

Precheck 1.7.1

Update PDK to d658698b

The filler generation has already considered these rules. The platform will automatically rerun the latest precheck for your designs.

Leo Moser (mole99) pinned a message to this channel. 2026-07-05 8:00 a.m.

@everyone

Critical update! If you are using the community-created 3.3V standard cell library for your tapeout, please update your design, as the PDK update fixes a critical issue.

Project Template 1.5.8

Update PDK to f6eeac7d
- Fix an issue in gf180mcu_as_sc_mcu7t3v3 regarding buffer cells.

Precheck 1.7.2

Fix the text ID generation for narrow letters such as "I".

If there are any questions, please let us know.

5

1

Leo Moser (mole99) pinned a message to this channel. 2026-07-14 1:22 p.m.

Leo Moser (mole99)

@everyone

Critical update! If you are using the community-created 3.3V standard cell library for your tapeout, please update your design, as the PDK update fixes a critical issue.

Project Template 1.5.8

Update PDK to f6eeac7d
- Fix an issue in gf180mcu_as_sc_mcu7t3v3 regarding buffer cells.

Precheck 1.7.2

Fix the text ID generation for narrow letters such as "I".

If there are any questions, please let us know.

This impacts us and while we have already updated, we are dealing with new timing violations. This is really inconvenient as we’re trying to make the deadline for Run2, what options do we have? (edited)

What kinds of timing violations?

Leo Moser (mole99) started a thread. 2026-07-14 6:50 p.m.

Obvious thing to try would be to exclude the newly added cells (mux4_1, mux4_2, oai21_2, oai21_4) that incidentally got added in the same pdk update. But if it's the improved timing of the buff_8 causing issues that is going to be harder to fix...

@Tholin taking a look now sorry it’s a long run from synth to pnr to gds so reports aren’t done yet on latest run

7:25 p.m.

Takes around 12 hrs

RebelMike

Obvious thing to try would be to exclude the newly added cells (mux4_1, mux4_2, oai21_2, oai21_4) that incidentally got added in the same pdk update. But if it's the improved timing of the buff_8 causing issues that is going to be harder to fix...

Just use a buf2 into a buf4 maybe?

Hi, I think there is an issue with the default template for the 1x0.5 slot. Seems to only have 54 IO pins, not the expected 56 : https://github.com/wafer-space/gf180mcu-project-template/blob/33194e694f02a392dcf561d7d9fbcc70714cf3af/src/slot_defines.svh#L33-L47 (edited)

gf180mcu-project-template/src/slot_defines.svh at 33194e694f02a392d...

Project template for wafer.space MPW runs using the gf180mcu PDK - wafer-space/gf180mcu-project-template

9:29 p.m.

@Essen was so nice as to help with the project wrapper aspects for the multiplexed e-test, but has run into breakage of some kind trying to set up the COB-supported default pad ring of the 1x0.5 slot.

9:29 p.m.

The repo where things are happening

~~Same for 0.5x0.5 it looks suss: 56 (48 IO + 8 power) But there are only have 46 ? Is there something I am missing here ?~~ (edited)

Ah ! I figure it out, I am in idiot

( I really need to sleep more ) It's clk and rst ! (edited)

9:48 p.m.

Sorry for the noise.

namibj

Click to see original message

this still applies though